Network virtualization entails creating logical, virtual networks that are decoupled from the underlying network hardware to ensure the network can better integrate with and support increasingly virtual environments. Some network virtualization platforms use flow based forwarding elements. Each flow is essentially a rule that specifies how the forwarding element should process each packet with certain header field values. The flow includes a set of match fields and at least one action to perform on each packet that has a set of header values that match the set of match field values. Examples of actions include dropping the packet or outputting the packet to one or more of the forwarding element's output ports.
Network virtualization platforms collect statistics for logical entities such as logical ports as well as statistics for interfaces such as virtual network interfaces (VIFs), physical network interfaces (PIFs), tunnels, etc. Some network virtualization platforms provide an application programming interface (API) and/or a user interface (UI) that shows different types of packet statistical counters for configured logical entities (e.g., ingress packet counts and bytes of a logical port, total drop count and bytes of a logical port, packet drop count and bytes of a logical port due to a particular security feature, etc.).
On open vSwitch (OVS) based platforms such as kernel-based virtual machine (KVM) hypervisors, packet statistics are aggregated from flow statistics. Specifically, statistics for each flow is programmed and installed in the forwarding element. Flows for which statistics are collected are programmed by a controller to also include a note action that includes the counter type and a unique identifier (such as universally unique identifier (UUID) of the logical entity). A daemon that runs on the host aggregates these statistics based on the note action before sending them to the management plane of the network virtualization platform. The daemon reads and sums up all flow statistics corresponding to the same unique identifier and counter type.
The flows installed by the controller are dependent on the features and configurations applied to a logical entity (e.g., media access control (MAC) address, distributed firewall, security, etc.). For instance, if address resolution protocol (ARP) snooping is enabled, the controller installs or removes the appropriate flows. Another example is when the MAC address of a logical port changes, then the controller installs new flows (and deletes the corresponding old flows) to reflect the new MAC address. The problem with this method is that flow statistics share the same lifetime of a flow. If a flow is deleted, then the corresponding statistics gets deleted too. This results in possible inaccurate or incomplete packet statistics reported to the management plane.
Previous solutions to ensure that logical entities statistics are accurate, involve adding additional intelligence in the daemon that collects and sends the statistics to the management plane. This requires the daemon to keep track of whether a flow has been churned and properly account for the statistics. This adds additional complexity to the daemon and the daemon has to handle different cases (such as ARP snooping, MAC address changes, etc.) in order to ensure logical entity statistics are accurate.